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(54) Method for reserving resources 

(57) A method for managing resources in a compu- 
ter system. 

According to one embodiment of the invention, a re- 
source manager receives a first request of a first oper- 
ation. The first request identifies a first resource and 
specifies an amount of the first resource needed to ex- 
ecute the first operation. In response : a resource man- 



ager determines if the amount of the first resource re- 
quested by the first request is available to be reserved. 
In response to the amount of the first resource request- 
ed by the first request being available to be reserved, 
the resource manager reserves the amount of the first 
resource requested by the first request in advance of 
allocating the first resource to the first operation. 
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Description 

FIELD OF THE INVENTION 

The present invention relates to computer systems, 5 
and, in particular, to reserving and managing computer 
system resources. 

BACKGROUND OF THE INVENTION 

w 

In computing environments such as embedded sys- 
tems, set-top boxes, or general purpose computers 
where resources (e.g. memory) are limited, software is 
developed to accommodate the uncertainty of whether 
resources needed tocomplete an operation will be avail- '5 
able. 

For general purpose computers, well written soft- 
ware requests resources as they become needed and 
verifies that the requested resources were actually pro- 
vided. If it is determined that a resources was not pro- 20 
vided : ihe operation being performed is aborted part- 
way through, and any resources allocated in earlier 
stages of the operation are returned to the system. 

In a system with scarce resources, however, this 
approach does not perform well. For example, if there 25 
are only enough resources available for one operation 
to execute until completion, but the system begins two 
operations, both operations may fail halfway through. 

Some systems attempt to solve this problem by 
dedicating pools of resources for specific operations 30 
This approach also has problems. 

Consider the example that we have two operations. 
A and B. Each operation is only allocated 100 bytes of 
memory. Further consider the case where operation A 
is not using its 100 bytes of memory and B needs 150 ss 
bytes of memory. Even though the 200 bytes of memory 
are available in the system, operation B cannot proceed 
since 100 bytes of the systems memory are only avail- 
able to operation A. 

Some programmers attempt to solve this problem -*o 
by preallocating resources. For example, if a program- 
mer knows that they need 100 bytes of memory at the 
start of an operation, another 100 bytes halfway 
through, and 100 bytes at the end of the operation, then 
the programmer would allocate 300 byles of memory -*s 
before beginning the operation. 

Preallocating resources, however, has at least 
three' drawbacks. First, in an object oriented environ- 
ment, there may be no way to allocate resources of the 
correct object type in advance. A programmer would so 
have to allocate uninitialized instances of a class and 
initialize them later However, many class implcmoniois 
prohibit the creation of uninitialized instances of thou 
class. 

Second, most code is not written with pioallocalion 
in mind. Therefore, when integrating code that has pi c- 
allocated resources with existing code thai has not prc- 
allocated any resources, there is no way to direct the 



existing code to use the resources that may have been 
preallocated. 

Third, preallocalion of resources prohibits intelli- 
gent management by the system. From the perspective 
of Ihe system, once a resource has been allocated, the 
resource is considered to be in use. Therefore, even if 
some of the resources that have been allocated are not 
actually in use, the system may not manage the allocat- 
ed resources (e.g., temporarily loan some of the allocat- 
ed memory to a separate operation). 

SUMMARY OF THE INVENTION 

One embodiment of the invention provides a meth- 
od for managing resources in a computer system. Ac- 
cording to one embodiment of the invention, a resource 
manager receives a first request of a first operation. The 
first request identifies a first resource and specifies an 
amount of the first resource needed to execute the first 
operation. In response, a resource manager determines 
if the amount of the first resource requested by the first 
request is available to be reserved. In response to the 
amount of the first resource requested by the first re- 
quest being available to be reserved, the resource man- 
ager leserves the amount of the first resource requested 
by the first request in advance of allocating the first re- 
source to the first operation. 

BRIEF DESCRIPTION OF THE DRAWINGS 

One embodiment of the invention is illustrated by 
way of example and not limitation in the figures of the 
accompanying drawings, in which like references indi- 
cate similar elements, and in which: 

Figure 1 illustrates a computer system capable of 
implementing one embodiment of the invention. 

Figure 2a is a flow diagram describing the steps in 
one embodiment of the invention. 

Figure 2b is a flow diagram describing the steps in 
one embodiment of the invention. 

DETAILED DESCRIPTION 

A method is described for reserving resources in 
.idv :nco of allocating the resources. 

■•Honing to Figure 1. Ihe computer system upon 
v.! • the one embodiment of the invention can be im- 
i.:- * • mod is shown as 100 Shown in the memory 104 
—putor system 100 is an operating system 110, 
• ■ Mitiols the execution of user application pro- 
.■•-! pfovidcs services such as scheduling, data 
. .! umiol and other dala management re- 

■ : n the operating system is Ihe resource 
' which is a control program responsible 
.ttion of the computer system's resources, 
'ii ;o manager 11 2could alternatively be stored 
< > 1 uipiiioi -readable medium, such as a magnetic 
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disk accessible via Ihe disk drive unit 120, shown in- 
cluded in Ihe computer system of Figure 1 . The resource 
manager 112 could also be stored on a separate com- 
puter system and accessed over a network connection 
to the computer system 1 00 via the network device 1 22 
also shown included in the computer system 100. 

Also included in the memory 1 04 is Ihe multi-thread- 
ed program 1 1 5, which as shown, is presently being ex- 
ecuted. In modern interactive software, a single pro- 
gram can be made up of multiple control flows, com- 
monly referred to as "threads of control" (threads). 
Threads extend the concept of switching between sev- 
eral different running programs (i.e. processes), to 
switching between several different functions executing 
simultaneously within a single program (fe., multitask- 
ing in a single program). As a result, higher throughput 
and belter performance of a single program is achieved 
because one thread can run while another thread is 
sleeping (e.g., fetching data from a disk). 

Multiple threads belonging to one program share 
the same address space, however each thread does 
have its own program counter (PC), register set, and 
stack. As a result, the overhead of switching between 
threads (e.g. saving the state of a few registers a stack 
pointer a program counter etc.) is considerably less 
than the overhead incurred when switching between 
processes (e.g. saving the state of virtual memory 
maps, file descriptors, etc.). 

Computer resources are allocated to each thread in 
order to complete the respective operation associated 
with each thread. The resources allocated could include 
random access memory, network bandwidth, a display, 
a printer, or any other device of Ihe computer system 
that can be allocated to an operation of a running pro- 
gram. 

In order to obtain the resources needed to complete 
execution of the operation, each thread submits a re- 
quest to the resource manager 112. The resource man- 
ager reads the request to determine the resource re- 
quested and the amount requested. The resource man- 
ager then reads the Resource Status Table 125 (RST) 
to determine if the requested amount of the requested 
resource is available. 

In one embodiment, the RST includes an available 
indicator for each resource, which shows how much of 
that particular resource is available to be reserved (e 
g., 127). In an alternative embodiment, a reserved indi- 
cator could be used to show the amount of each re- 
source that is presently reserved 

If the requested amount of the requested resource 
is available, Ihe resource manager reserves the re- 
quested amount of the requesled resource (hereinafter 
referred to as the reserved resource) On the other 
hand, if the requested amount of the requested resource 
is not available, the requesting thread may choose not 
to begin its operation. 

When reserving the requested amount of the re- 
quested resource, the resource manager inserts an en- 



try into the Reservation Table 1 30 for the reserved re- 
source. Each entry in the Reservation Table identifies 
the reserved resource, the amount of the resource re- 
served, and the thread that has reserved the resource. 
5 In addition, the resource manager updates the RST to 
reflect the reservation. 

Sometime after the reservation, the reserved re- 
source is allocated to the thread for which it has been 
reserved. By reserving a part of a resource for a request 
'0 prior to allocating the resource to the request, the thread 
requesting the resource is certain to have enough of the 
resource to complete its operation. 

When the reserved resource is allocated to the re- 
questing thread, the resource manager updates the In- 
'5 use Table 145 (IT) to show the reserved resource is 
presently allocated to a thread. When a resource has 
been allocated to a thread it is assumed, from the per- 
spective of the resource manager and the computer sys- 
tem, that the amount of the resource that has been al- 
20 located is in use. 

In alternative embodiments, the invention provides 
a manner of intelligently managing the resources that 
have been reserved. For example, by separating the 
reservation of resources from the allocation of resourc- 
es es, a system may know which resources are currently 
being used and which resources are not being used. As 
a result, resources not in use. but reserved by a thread 
can be temporarily loaned to a higher priority operation. 
Referring to Figure 2. a flow diagram is illustrated 
30 describing the steps of Ihe performing the invention ac- 
cording to one embodiment. In block 202, a thread sub- 
mits a request to the resource manager to obtain the 
resources need to complete execution of an operation 
associated with the thread. In one embodiment, each 
35 request of a thread identifies a resource, Ihe amount re- 
quested, and the priority of the request. In alternative 
embodiments, the requesting thread may also include 
its own priority relative the other threads of the program 
115. 

•*o After reading the request of a thread., in decision 
block 204. the resource manager reads the available in- 
dicator (eg. 127) of the Resource Status Table 125 
(RST) to determine if the requested amount of the re- 
quested resource is available to be reserved. In an al- 

^5 tcrnative embodiment, in decision block 204 the re- 
source manager may also determine whether the 
amount of the requested resource is available to be re- 
served is below a predetermined threshold, wherein the 
amount of Ihe requested resource available lo be re- 

50 served would be considered relatively low. 

II the requested amount of Ihe requested resource 
is available or in the alternative embodiment, exceeds 
the picdGjcmunccl threshold in block 206 the resource 
manager reserves the requested amount of the requesl- 

55 cd resource (hereinafter referred to as the reserved re- 
source) 

More specifically, the resource manager inserts an 
entry 1 38 into the Reservation Table 1 30. In one embod- 
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iment, each entry of the Reservation Table identifies the 
requested resource 1 31 . theamount of the resource that 
is being reserved for the requesting thread 132, the 
thread that has requested the resource 133, the priority 
of the request as normal or non-essential 1 34 : and pos- 
sibly indicate the priority of the requesting thread 135. 
In alternative embodiments, the entries of the RST may 
vary within the scope of the invention, so long as they 
indicate which resources have been allocated. Moreo- 
ver the priority levels other than normal or non-essential 
can be assigned to the request of each requesting 
thread without deviating from the scope of the invention. 

In block 208, the resource manager updates the 
available indicator 127 of the RST to show that the re- 
served resource is not available to be reserved 

In block 210, sometime after the resource manager 
has reserved the requested amount of the requested re- 
source, the reserved resource is dynamically allocated 
to the respective thread for which it has been reserved. 
The dynamic allocation is defined as allocating portions 
of the reserved resource to the requesting thread as the 
reserved resource is needed by the requesting thread. 

In response to part of the reserved resource being 
dynamically allocated to the requesting thread, in block 
212, the resource manager updates the In-use Table 
145 to show the amount of the reserved resource that 
is presently allocated to the thread which has requested 
the resource. In one embodiment, each entry of the In- 
use Table may indicate the resource 146, the amount 
presently allocated 147, and thread to which the re- 
source has been allocated 148. 

For example, if a threadl has reserved 100 kilo- 
bytes (K) of memory, but initially is only allocated 25K, 
the entry for threadl 's In-Use table will indicateonly 25K 
has been allocated to threadl. Moreover, if threadl is 
initially allocated 100K of memory and part way through 
its execution, threadl is finished with 50K of the memory, 
the resource manager may update threadl's entry to 
show that only 50K of memory is now allocated to 
threadl. 

In one embodiment, if the resource manager deter- 
mines in decision block 204 that the requested amount 
of the requested resource is not available, or in the al- 
ternative embodiment, determines that the amount 
available is below the predetermined threshold, the re- 
source manager attempts to suspend a prior request. In 
an alternative embodiment, when the requested re- 
source is below the predetermined level, the resouicc 
manager may be programmed to reject the request if 
the request is non-essential or the priority of the thread 
requesting the resource is below a predetermined level 
of priority. 

When attempting to suspend a prior request in 
block 214. the resource manager reads the Reservation 
table to find a prior request of a separate thread that lias 
already reserved enough of the requested tcsource to 
satisfy the present request which has been unable to 
reserve part of the requested resource In an alternative 



embodiment, the resource manager may attempt to sus- 
pend a group of prior requests, which together have re- 
served enough of the requested resource to satisfy the 
present request. 

5 Once the resource manager has found a prior re- 
quest which has reserved enough of the requested re- 
source to satisfy the present request, in block 216, the 
resource manager reads the In-use Table to determine 
how much of the requested resource has been allocated 

io to the prior request. If the requested resource is unallo- 
cated to the prior request, or if enough of the requested 
resource to satisfy the present request is unallocated to 
the prior request, in decision block 218, the resource 
manager performs a logical comparison between the 

'5 prior request and the present request. Otherwise, in 
block 217, the resource manager rejects the present re- 
quest. 

The logical comparison performed by the resource 
manager in block 218 is predetermined. The logical 

20 comparison, for example, may compare the priority of 
the present request with the priority of the prior request, 
and/or the priority of the present requesting thread to 
the priority of the prior requesting thread. 

If the prior request exceeds the present request in 

25 the comparison, in block 220. the resource manager will 
reject the present request or attempt to suspend another 
prior request. On the other hand, if the present request 
exceeds the prior request in the logical comparison in 
block 222 the resource manager will temporarily sus- 

30 pend the prior request and insert an entry in the reser- 
vation table for the present request. Suspending the pri- 
or request is transparent to a user of the computer sys- 
tem. 

In one embodiment, the entry of the present request 

3$ in the Reservation Table will include a pointer 1 37 to the 
suspended prior request. As a result, when the present 
request is finished with the requested resource, the re- 
source manager will read the pointer to determine which 
prior request to unsuspend. Moreover, the entry of the 

•to suspended request in the Reservation Table, may in- 
clude a field 136 that is set to indicate the respective 
request is presently suspended. 

Consider the example shown in the memory of Fig- 
ure \ The third thread 138 submitted a request to the 
resource manager to obtain 150K of memory The re- 
source managers read the RST and determined that all 
of memory has been reserved. The resource manager 
then read the reservation table and saw that the second 
thread 139 has reserved 150K of memory, enough to 

50 satisfy the request of the third thread 139. 

The resource manager then compared the priority 
ol the third thread's request (or memory (noimal) with 
the pHOiily ol the second thread's request for memory 
(non-essential) The resource manager may also have 

55 compared the priority of the third request (2nd) to the 
priority of the second request (9th) 

After, the resource manager had determined the 
ihncl thread's request exceeded the second thread's re- 
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quest, the resource manager then read the In-use table 
and determined that no memory had been allocated to 
the second thread. As a result, the resource manager 
suspended the request of the second thread 139 and 
inserted an entry into the Reservation Table for the re- 
quest of the third thread 138. 

The entry in the Reservation Table for the request 
of the third thread 139 includes a pointer to the request 
of the second thread. As a result, after the third thread 
is finished with the memory, the resource manager will 
read the pointer of the request for the third thread and 
unsuspend the second thread's request for memory, as 
is shown in block 224. 

In the foregoing specification the invention has 
been described with reference to specific exemplary 
embodiments thereof. It will, however be evident that 
various modifications and changes may be made there- 
to without departing from the broader spirit and scope 
of the invention. For instance, where it has been shown 
that the resource manager including the RST, the In- 
use Table, and the Reservation Table are in memory 
104, these items may also be stored on a magnetic or 
optical disk and accessed via the disk drive 1 20. 

The specification and drawings are, accordingly to 
be regarded in an illustrative rather than restrictive 
sense. Moreover, the following claims indicate the 
scope of the invention, and all variations which come 
within the meaning and range of equivalency of the 
claims are to be embraced within their scope. 
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3. The computer-implemented method of claim 2, fur- 
ther including the step of: 

in response to the amount of the first resource 
being unavailable to be reserved, the resource 
manager rejecting the first request. 

4. The computer-implemented method of claim 2, 
wherein the resource manager includes a resource 
status table, said resource status table indicates an 
amount of the first resource available to be reserved 
by a thread; 

"said resource manager includes a reservation 
table, said reservation table stores resource 
reservations for the set of threads, wherein 
each entry in the reservation table identifies a 
resource, an amount of the resource reserved, 
a thread for which the resource has been re- 
served, and a priority of the request of the 
thread for which the resource has been re- 
served, and 

said resource manager further includes an in- 
use table., said in-use table indicates an amount 
of a resource having been allocated to a thread. 

5. The computer-implemented method of claim 4, 
wherein the step of determining if the amount of the 
first resource specified by the first request is avail- 
able, further includes reading the resource status 
table to determine if the amount of the first resource 
specified by the first request, is available to be re- 
served. 



1. A computer-implemented method for managing re- 6. 
sources in a computer system comprising the steps 35 
of: 

a resource manager receiving a first request of 
a first operation, said first request identifies a 
first resource and specifies an amount of the -to 
first resource needed to execute the first oper- 
ation: 

the resource manager determining if the 7. 
amount of the first resource specified by the 
first request, is available to be reserved and -*5 
in response to the amount of the first resource 
specified in (he first request being available to 
be reserved, the resource manager reserving 
the amount of the first resource specified in the 
first request in advance of allocating iho first re- so 
source to the first operation. 8. 

2. The computer-implemented method of claim 1 
wherein the first operation is a first thread, said lirst 
thread is one of a set of threads belonging to one S5 
program, said set of threads sharing one address 
space, and each thread of saidsel of threads is al- 
located an individual program counter 



The computer-implemented method of claim 5. 
wherein the step of the resource manager reserving 
further includes the steps of: 

inserting an entry into the reservation table: and 
updating the resource status table to indicate 
the amount of the first resource specified in the 
first request is unavailable to be reserved. 

The computer-implemented method of claim 6, fur- 
ther including the step of: 

dynamically allocating at least a part of the 
first resource to the first thread, wherein the re- 
source manager updates the in-use table to indicate 
the part of the lirst resource presently allocated to 
the first thread. 

The computer-implemented method of claim 7, fur- 
ther including the steps of. 

in response to the fust thread being finished 
with the first resource, updating the resource 
•status table to indicate an amount of the first 
resource allocated to the first thread is availa- 
ble to be reserved. 
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and updating the in-use table to indicate the 
amount of the first resource allocated to the first 
thread is available to be allocated. 

9. The computer- implemented method of claim 8, s 
wherein the step of the resource manager determin- 
ing if the amount of the first resource specified. by 
the first request is available further includes the 
steps of: 

the resource manager reading the resource to 
status table to determine if an amount of the first 
resource available to be reserved is below a prede- 
termined threshold. 

10. The computer-implemented method of claim 9 : fur- '5 
ther including the step of: 

in response to the amount of the first resource 
available to be reserved being below the predeter- 
mined threshold and the priority of the first request 
being nonessential or a priority of first thread being 20 
below a predetermined priority, the resource man- 
ager rejecting the first request 

11. The computer-implemented method of claim 10. 
wherein the step of the resource manager determin- 25 
ing if the amount of the first resource specified by 

the first request is available to be reserved, further 
includes the steps of: 

in response to the amount of the first resource 30 
specified by the first request being unavailable 
or the amount of the first resource available to 
be reserved being below the predetermined 
threshold, the resource manager petforminq a 
predetermined logical comparison of the first 35 
request of the first thread to a second request 
of a second thread, said resource manager 
having reserved at least a part of the first re- 
source for the second request in advance of al- 
locating the first resource to the second thread- -to 
and 

in response to the first request of the first thread 
exceeding the second request of the second 
thread in the logical comparison, the resource 
manager temporarily suspending the second •*$ 
request of the second thread and reserving at 
least a part of the first resource for the first re- 
quest of the first thread 

12. The computer-implemented method of claim 11, fur- 50 
ther comprising the steps of' 

unsuspending the second request ol the sec- 
ond thread after the first thread is finished with the 
first resource. 

55 

13. The computer-implemented method of claim 12. 
further includes the step of. 

in response to the second lequcst of the sec- 



ond thread exceeding the first request of the first 
thread in the logical comparison, the resource man- 
ager rejecting the first request of the first thread. 

1 4. The computer-implemented method of the claim 1 3, 
wherein the resource manager is part of an operat- 
ing system of a limited resource computer system. 

15. A computer-readable medium having stored there- 
on a plurality of sequences of instructions, said se- 
quences of instructions including instructions 
which, when executed by a processor, cause said 
processor to perform the steps of: 

receiving a first request of a first operation, said 
first request identifies a first resource and spec- 
ifies an amount of the first resource needed to 
execute the first operation: 
determining if the amount of the first resource 
specified by the first request, is available to be 
reserved: and 

in response to the amount of the first resource 
specified in the first request being available to 
be rescived. reserving the amount of the first 
resource specified in the first request in ad- 
vance of allocating the first resource to the first 
operation. 

1 6. The computer-readable medium of claim 1 5, where- 
in the first operation is a first thread., said first thread 
is one of a set of threads belonging to one program, 
said set of threads sharing one address space, and 
each thread of said set of threads is allocated an 
individual program counter. 

17. The computer-readable medium of claim 16. further 
having stored thereon additional instructions which, 
when executed by a processor, cause said proces- 
sor to perform the step of: 

in response to the amount of the first resource 
being unavailable to be reserved, rejecting the first 
request. 

18. The computer-readable medium of claim 16, further 
having stored thereon a resource manager, the re- 
source manager includes a resource status table, 
said resource status table indicates an amount of 
the first resource available to be reserved by a 
thread. 

said resource manager includes a reservation 
table, said reservation table stores resource 
reservations for the set of threads, wherein 
each entry in the reservation table identifies a 
resource, an amount of the resource reserved, 
a thread for which the resource has been re- 
served, and a priority of the request of the 
thread for which the resource has been re- 
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served, and 

said resource manager further includes an in- 
use table, said in-use table indicates an amount 
of a resource having been allocated to a thread. 

5 

1 9. The computer-readable medium of claim 1 8, where- 
in the step of determining if the amount of the first 
resource specified by the first request is available, 
further includes reading the resource status table to 
determine if the amount of the first resource sped- to 
fied by the first request, is available to be reserved. 

20. The computer-readable medium of claim 1 9, where- 
in the step of the resource manager reserving fur- 
ther includes the steps of' IS 

inserting an entry into the reservation table: and 
updating the resource status table to indicate 
the amount of the first resource specified in the 
first request is unavailable to be reserved. 20 

21. The computer-readable medium of claim 20, further 
having stored thereon additional instructions which, 
when executed by a processor, cause said proces- 
sor to perform the step of: the step ol: "5 

dynamically allocating at least a pan of the 
first resource to the first thread, wherein the re- 
source manager updates the in-use table to indicate 
the part of the first resource presently allocated to 
the first thread. 30 

22. The computer-readable medium of claim 2 1 . further 
having stored thereon additional instructions which, 
when executed by a processor, cause said proces- 
sor to perform the step of" 35 

in response to the first thread being finished 
with the first resource, updating the resource 
status table to indicate an amount of the first 
resource allocated to the first thread is availa- -to 
ble to be reserved, 

and updating the in-use table to indicate the 
amount of the first resource allocated to the first 
thread is available to be allocated. 

45 

23. The computer-readable medium of claim 22, where- 
in the step of determining if the amount of the first 
resource specified by the first request is available 
further includes the steps of: 

the resource manager reading the resource so 
status table to determine if an amount of the first 
resource available to be reserved is below ri prede- 
termined threshold 

24. The computer-readable medium of claim 23. fuither 55 
having stored thereon additional instructions which, 
when executed by a processor, cause said proces- 
sor to perform the step of 



in response to the amount of the first resource 
available to be reserved being below the predeter- 
mined threshold and the priority of the first request 
being nonessential or a priority of first thread being 
below a predetermined priority, the resource man- 
ager rejecting the first request. 

25. The computer-readable medium of claim 23, where- 
in the step of determining if the amount of the first 
resource specified by the first request is available 
to be reserved, further includes the steps of: 

in response to the amount of the first resource 
specified by the first request being unavailable 
or the amount of the first resource available to 
be reserved being below the predetermined 
threshold, the resource manager performing a 
predetermined logical comparison of the first 
request of the first thread to a second request 
of a second thread, said resource manager 
having reserved at least a part of the first re- 
source for the second request in advance of al- 
locating the first resource to the second thread: 
and 

in response to the first request of the first thread 
exceeding the second request of the second 
thread in the logical comparison, the resource 
manager temporarily suspending the second 
request of the second thread and reserving at 
least a part of the first resource for the first re- 
quest of the first thread. 

26. The computer-readable medium of claim 25.. further 
having stored thereon additional instructions which, 
when executed by a processor cause said proces- 
sor to perform the step of: 

unsuspending the second request of the sec- 
ond thread after the first thread is finished with the 
lirst resource. 

27. The computer-readable medium of claim 26 : further 
having stored thereon additional instructions which, 
when executed by a processor, cause said proces- 
sor to perform the step of: 

in response to the second request of the sec- 
ond thread exceeding the first request of the first 
thread in the logical comparison, the resource man- 
ager rejecting the first request of the first thread 

28. The computer-readable medium of the claim 27 
wherein the resource manager is part of an operat- 
ing system ol a limited resource computer system 

29. A computer system configured to manage resourc- 
es the computer system comprising of: 

a resource manager configured to receive a 
first request of a first operation, said first re- 



13 



EP 0 817 041 A2 



14 



quest identifies a first resource and specifies an 
amount of the first resource needed to execute 
the first operation: 

the resource manager further configured to de- 
termine if the amount of the first resource spec- 
ified by the first request, is available to be re- 
served: and 

the resource manager further configured to re- 
serve, in response to the amount of the first re- 
source specified in the first request being avail- 
able to be reserved, the amount of the first re- 
source specified in the first request in advance 
of allocating the first resource to the first oper- 
ation. 

30. The computer system of claim 29, wherein the first 
operation is a first thread, said first thread is one of 
a set of threads belonging to one program, said set 
of threads sharing one address space, and each 
thread of said set of threads is allocated an individ- 
ual program counter. 

31. The computer system of claim 30. wherein ihe re- 
source manager is further configured to reject the 
first request in response to the amount of the first 
resource being unavailable to be reserved. 

32. The computer system of claim 30, wherein the re- 
source manager includes a resource status table, 
said resource status table indicates an amount of 
the first resource available to be reserved by a 
thread: 

said resource manager includes a reseivation 
table, said reservation table stores resource 
reservations for the set of threads, wherein 
each entry in the reservation table identifies a 
resource, an amount of the resource reserved, 
a thread for which the resource has been re- 
served, and a priority of the request of the 
thread for which the resource has been re- 
served, and 

said resource manager further includes an in- 
use table, said in-use table indicates an amount 
of a resource having been allocated to a thread 

33. The computer system of claim 32. wherein the re- 
source manager is configured to read the resource 
status table to determine if the amount of the first 
resource specified by the first request is available 
to be reserved. 

34. The computer system of claim 33 wherein resource 
manager is configured to insert an entry into the res- 
ervation table and update the resource status table 
to indicate the amount of the first resouice specified 
in the first request is unavailable to be reserved, m 
order to reserve the amount of the first resource 



specified in the first request. 

35. The computer system of claim 34, wherein the re- 
source manager is configured to dynamically alio- 
5 cate at least a part of the first resource to the first 
thread and update the in-use table to indicate the 
part of the first resource presently allocated to the 
first thread. 

'0 36. The computer system of claim 35, wherein the re- 
source manager is configured to update, in re- 
sponse to the first thread being finished with the first 
resource : the resource status table to indicate an 
amount of the first resource allocated to the first 

is thread is available to be reserved, and update ihe 
in-use table to indicate the amount of the first re- 
source allocated to the first thread is available to be 
allocated. 

20 37. The computer system of claim 36, wherein Ihe re- 
source manager is configured to read the resource 
status table to determine if an amount of the first 
resouice available to be reserved is below a prede- 
termined threshold. 

25 

38. The computer system of claim 37, the resource 
manager is configured to reject the first request in 
response to the amount of the first resource avail- 
able to be reserved being below the predetermined 

30 threshold and the priority of the first request being 
nonessential or a priority of first thread being below 
a predetermined priority. 

39. The computer system of claim 37, wherein the re- 
JS source manager is configured to perform, in re- 
sponse to the amount of the first resource specified 
by the first request being unavailable or the amount 
of the first resource available to be reserved being 
below the predetermined threshold, a predeter- 

•*o mined logical comparison of the first request of the 
first thread to a second request of a second thread, 
said resource manager having reserved at least a 
part of the first resource for the second request in 
advance of allocating the first resource to the sec- 

•*s ond thread, and 

the resource manager further configured to 
temporarily suspend, in response to the first request 
of the tirst threadexceeding the second request of 
the second thread in the logical comparison, the 

50 second request of the second thread and reserve 
at least a part of the first resource for the fiist re- 
quest- of Ihe first thread. 

40. The computer system of claim 39. wherein the to- 
ss souico manager configured to unsuspend the sec- 
ond request of the second thread after the first 
thread is finished with the first resource. 



rt 
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The computer system of claim 40. wherein the re- 
source manager is configured to reject the first re- 
quest in response to the second request of the sec- 
ond thread exceeding the first request of the first 
thread in the logical comparison. s 

The computer system of the claim 41, wherein the 
resource manager is part of an operating system of 
a limited resource computer system. 
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